Additional findings after instrumenting our apps and reproducing this on device: When the alarm is dismissed by touching the bottom notch area, NEITHER the stopIntent nor the secondaryIntent we supply through AlarmPresentation is executed. The app gets no callback of any kind, so we cannot distinguish an intentional stop from this accidental dismissal. The daemon state is left inconsistent after this dismissal. The alarm's entry in AlarmManager.shared.alarms stays in the .alerting state even though the alert UI is gone and no sound is playing. We confirmed via AVAudioSession that nothing is audible while the entry still reports .alerting. A normal stop (slide to stop, or our stop intent) transitions the alarm out of .alerting, and a recurring alarm re-rolls to .scheduled. Steps to verify the state issue: schedule a recurring AlarmKit alarm, let it fire on the locked phone, touch the bottom notch area so the alert dismisses, then read AlarmManager.shared.alarms from the app. The entry remains .alerting indefinitely until the app force-stops it. We reproduced this consistently on iOS 26.6 (23G71) and 26.6.1 (23G82). Our production analytics also show roughly 3.5% of monthly active users hitting our defensive recovery path for stuck-.alerting entries, which matches this dismissal happening regularly in real use: users grab the ringing phone, touch that area accidentally, and the alarm dies silently. This may be related to the reports in developer forums thread 815064 ("AlarmKit - Behaviors when dismissing alarms"), where stopIntent does not execute for some dismissal paths. Impact: users miss the alarm flow entirely (our secondary button never runs), developers cannot tell intentional stops from accidental ones, and every affected fire leaves a wedged .alerting entry that we have to detect and force-stop defensively.

Hi everyone, Adding our experience, no fix either, but production data that may help triangulate. We've filed FB22638314 corroborating SeoulForest's FB22327481. Context Bird Rise alarm app: a new bird wakes the user up every day. AlarmKit on iOS 26.2+. The bug: The off-hours misfire rate. Across ~13,000 firings in 30 days, <0.5% of users intend evening or night alarms (84% schedule for 06:00–09:59), yet ~10–15% of actual rings land in the 21:00–01:00 window. Same on iOS 26.1 through 26.5. This matches the "fires around midnight" / "fires at random times" pattern described upthread. App Store reviews reporting the alarm continues to fire after the app has been uninstalled. 🤯 We've ruled out app-side causes: no EventKit, no server push, no app groups, no third-party schedulers; AlarmKit is the only persistent scheduling we use. Pattern looks similar to the zombie Live Activity on thread 819556. I was never able to catch those issues on my devices. Would appreciate any guidance from anyone who's gotten further with this.

I have refactored my code using your approach @ekurutepe and still get users complaining about the same issue (random or midnight alarms). There are also some people complaining that they uninstalled the app but still receive the alarms.

Thanks for details @Hakoniwa . I have refactored my code many times and still get users complaining about the same issue (random or midnight alarms). There are also some people complaining that they uninstalled the app but still receive the alarms.

@ekurutepe Dang, I'm doing exactly what you were doing. I'll try your new approach. Thanks.

Working fine here, but I decided to implement it only for 26.2+ because the API versions before that were not as reliable. Remember to first request authorization like this: func requestAuthorization() async -> (granted: Bool, status: String) { do { let state = try await AlarmManager.shared.requestAuthorization() let stateString: String switch state { case .authorized: stateString = "Authorized" case .denied: stateString = "Denied" case .notDetermined: stateString = "Not Determined" @unknown default: stateString = "Unknown" } let granted = state == .authorized print("[AlarmKit] Authorization state: (stateString)") return (granted, stateString) } catch { print("[AlarmKit] Authorization error: (error)") return (false, "Error") } }

Yep, it plays fine now! I recommend sounds shorter than 30 seconds.

Same here! Many users are complaining about that. I spent a huge amount of time refactoring and testing but could never emulate it.